Require blessed python-backend SHA for desktop stable promotion - #9400
Require blessed python-backend SHA for desktop stable promotion#9400Git-on-my-level wants to merge 2 commits into
Conversation
|
@cursor address merge conflict |
|
Merge conflict resolved and pushed. Conflict: Resolution: Combined both sides:
Verification: All four policy/test scripts passed. Status: PR #9400 is now MERGEABLE (no conflicts). Commit: |
Stable promotion now takes python_backend_sha, validates the python-backend-bless release plus ancestry, and reuses audited break-glass to bypass those checks after the #9380 lifecycle. Co-authored-by: Cursor <cursoragent@cursor.com>
Committee Improve-then-ship: move attestation+ancestry checks into a hermetic script, skip the entire coupling gate on desktop break-glass (no unblessed phrase bridge), and record live_prod_check: NOT_RUN honesty in the promote workflow summary. Co-authored-by: Cursor <cursoragent@cursor.com>
49d0831 to
03f1402
Compare
Monitor summary — rebased onto latest
|
|
Superseded by the Release Eligibility proof mechanism (#9993, #9998) now documented in AGENTS.md as the single evidence contract for promotion, with break-glass hatches per surface. Requiring a separate python-backend-bless- attestation on desktop stable promotion would add a competing gate. Draft has been conflicting since 2026-07-12. |
|
Hey @Git-on-my-level 👋 Thank you so much for taking the time to contribute to Omi! We truly appreciate you putting in the effort to submit this pull request. After careful review, we've decided not to merge this particular PR. Please don't take this personally — we genuinely try to merge as many contributions as possible, but sometimes we have to make tough calls based on:
Before your next PR, please skim:
If this was declined for direction or taste, maintainers should cite an invariant ID or open a proposed one — ask if that citation is missing. Your contribution is still valuable to us, and we'd love to see you contribute again in the future! If you'd like feedback on how to improve this PR or want to discuss alternative approaches, please don't hesitate to reach out. Thank you for being part of the Omi community! |


Summary
python_backend_shaondesktop_promote_prod.ymland validate the matchingpython-backend-bless-<sha>attestation (ancestor of the desktop release SHA).github/scripts/check-desktop-python-backend-coupling.pywith hermetic tests wired inrepo-checks.ymlI-ACCEPT-STABLE-PROMOTION-RISK+ reason), skip the entire python coupling gate — noI-ACCEPT-UNBLESSED-PROD-RISK/--override-unblessedbridge, no fake release JSONlive_prod_check: NOT_RUN(attestation ≠ live prod; short-SHA Cloud Run tags stay runbook-only)python-backend-bless-,bless-python-backend.sh,check-python-backend-blessing.py); operator language uses attestation/attested--desktop-target-sha/--python-backend-shaand forbids hardcoded unblessed override phrase in the promote workflowSupersedes #9204
Rebuilt on current
mainafter #9380 (qualification / stable-candidate lifecycle). Committee Improve-then-ship consensus applied on top of the initial gate.Backend prod deploy blessing gate is a separate PR (successor to #9203); this PR stays independent because the python-backend blessing checker scripts are already on
main.Test plan
python3 .github/scripts/test_check_desktop_python_backend_coupling.pypython3 .github/scripts/check-desktop-prod-promotion-policy.pypython3 .github/scripts/check-desktop-release-terminology.pypython3 .github/scripts/test_check_desktop_release_promotion.pypython3 .github/scripts/test_check_python_backend_blessing.pyactionlint .github/workflows/desktop_promote_prod.yml